Don't we need to usermod as well?

AFAIU the usermod change is just to be able to run docker commands without sudo. In fact, in my test machine, docker is running after this command.

Probably user on your test machine has root access, and ability to run docker commands without sudo is super important, so it must be a part of initialization.

Why is it important?

Because it's a major security prerequisite. Giving docker root access is a bad idea (and in general, you should never give sudo access to anything unless there is a strong request for it). And, well, it's just not convenient to have always run commands with sudo. Plus it will break e.g. zkstack CLI because it will (correctly) run docker commands without sudo.

Regarding security, I'd argue exactly the reverse. With sudo you have to input a password for any docker command, thus requiring human approval. If you add the user to the docker group you effectively allow any app with non-root privileges access to the docker commands.
https://www.reddit.com/r/docker/comments/syngw7/to_sudo_or_not_to_sudo_that_is_the_question/

But yeah, if zkstack breaks, then usermod is needed.

I am also hesitatnt to suggest blindly running it. If the script will be run on a machine where, e.g., docker is already installed (especially if it was installed in some other way), it can mess up the configuration.

Do we really need to have a script here? If so, I'd probably want to make it fail-proof, e.g. that it won't do stuff that is not needed, but it's a much bigger effort.

The benefit of a code block is that you see the code and can choose what lines you need and what lines you don't need.

If we are to keep this, I'd add some big red warning that you should first read the script code and make sure that it does what you need (which though would render it much less helpful).

Fair enough, but the original setup guide specifically says that the code is to be run on a fresh GCP instance. So it seems reasonable that we have a fast setup option for those cases at least.
I can add a code block below with what's in the script, so that people can inspect it though.

Original -- yes, the new one removed mention of GCP.
Regarding code block -- it would mean duplication, and script will likely get out of sync with the code block.

I don't really think it's possible to create a fail-proof version of this script (at least without a disproportionate amount of work). And if we don't want duplication then the only possible solution is for me to close this PR.

I don't really think it's possible to create a fail-proof version of this script (at least without a disproportionate amount of work).

Yup, I agree, and that's exactly the reason why it wasn't done before.

And if we don't want duplication then the only possible solution is for me to close this PR.

Was there any reason why we need a script except for making usage simpler?

No, just to make usage simpler. I created one for myself, since I have to run fresh dev nodes with some frequency, and thought it would be useful for more people.

These lines are important for VMs, because submodule fetching may break if running on a fresh machine without valid ssh keys; however they're missing in the script.

The standard now really is to declare submodules with https, like we do. I did follow the tree of submodules down and it seems all of them use https.
Do you think it's worth it to keep this, since it's such a small edge case?